home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 001391_daemon _Mon Jun 21 17:58:14 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  5KB
  1. Received: by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  2.     id AA10219; Mon, 21 Jun 93 17:58:16 MET DST
  3. Return-Path: <dale@ora.com>
  4. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  5.     id AA10213; Mon, 21 Jun 93 17:58:14 MET DST
  6. Received: from ruby.ora.com by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  7.     id AA10781; Mon, 21 Jun 1993 18:20:34 +0200
  8. Received: from rock.west.ora.com by ora.com (5.65c/Spike-2.1)
  9.     id AA07640; Mon, 21 Jun 1993 12:20:19 -0400
  10. Received: from cider.west.ora.com by rock.west.ora.com (5.65c/Spike-2.1)
  11.     id AA21066; Mon, 21 Jun 1993 09:20:15 -0700
  12. Received: by cider.west.ora.com (5.65c/Spike-2.1)
  13.     id AA03348; Mon, 21 Jun 1993 09:21:36 -0700
  14. From: dale@ora.com (Dale Dougherty)
  15. Message-Id: <9306210921.ZM3346@cider.west.ora.com>
  16. Date: Mon, 21 Jun 1993 09:21:35 -0700
  17. In-Reply-To: Dave_Raggett <dsr@hplb.hpl.hp.com>
  18.         "HyTime compatibility (was  Re: HTML spec)" (Jun 21,  9:55am)
  19. References: <9306210855.AA12632@manuel.hpl.hp.com>
  20. X-Mailer: Z-Mail (2.1.0 10/1/92)
  21. To: Dave_Raggett <dsr@hplb.hpl.hp.com>
  22. Subject: Re: HyTime compatibility (was  Re: HTML spec)
  23. Cc: www-talk@nxoc01.cern.ch
  24.  
  25. Dave,
  26.  
  27. In my opinion, HyTime is not a useful direction for
  28. WWW at this time.  It will require a lot of effort just to
  29. understand, and even more to implement on a basic level.  As
  30. part of the Davenport Group, I spent more than a year
  31. investigating HyTime for possible use in Docbook DTD and other
  32. online publishing activities.  I did not see broad support
  33. for HyTime, as a standard or as technology.  I
  34. decided that HyTime was not something to be used by our
  35. current or next generation of technology. I was also very
  36. frustrated that HyTime exists only on paper, and so anyone
  37. can say anything about it without proving it in practice.
  38.  
  39. You have to separate out the claims made for HyTime and the technology
  40. or applications required to make use of it.  Most people
  41. who talk HyTime do not bother to distinguish between the two
  42. and they tend to trivialize the impact on applications. 
  43. Remember, there are no HyTime engines available anywhere
  44. and until there are no one can prove or disprove their claims.
  45. When someone says "HyTime allows you to do ....", probe for
  46. specifics.  Ask how it works.
  47.  
  48. You will also have trouble figuring out whether HyTime is
  49. a standard syntactical representation for hypermedia constructs
  50. or a way of life.  If the latter, then you have to
  51. start living that way now, or be lost.  (And that's why
  52. most HyTime advocates urge you to accept HyTime now.)  If it is just
  53. a standard representation of the kind of things we are already
  54. doing, then the door is always open to use that syntax,
  55. should it emerge as something of value.  
  56.  
  57. HyTime is intended to be an interchange standard, and its
  58. awkward syntax is not meant to be processed in real-time.
  59. If you study the standard, you will find out that for
  60. the most part, its method of standard representation involves
  61. putting a standard "wrapper" around application-specific info.  
  62. So, for instance, it allows HyTime apps to identify links 
  63. in a standard way, but it does not make the link addressing used in
  64. applications interoperable.  In WWW, we use URLs for link addressing
  65. and if we send an HTML document to another 
  66. hypermedia application, the tough part to interchange is the URL.
  67. If the target app does not understand URLs, the document is
  68. pretty useless.  All HyTime would do is put the URL in 
  69. a standard wrapper indicating that the tag contained link information.  
  70.  
  71. We should be aware of HyTime -- there are some challenging
  72. ideas in it that go way beyond linking. However, we should
  73. not ignore the absence of HyTime-based technology -- none was 
  74. developed to test the specification as part of the standardization 
  75. process. If you take the view that
  76. HyTime offers a standard representation for hypermedia documents, 
  77. then we should be able to convert HTML documents into
  78. a form that is HyTime-compliant for the purpose of interchanging
  79. documents with other HyTime-supporting apps,
  80. (which do not yet exist).   As long as our focus is
  81. on creating documents to be used in the Web, 
  82. we don't need to be encumbered by HyTime syntax, much
  83. less by the HyTime way of thinking.  Anyone who feels HyTime
  84. is important is free to manage his information using
  85. HyTime-compliant DTDs and then create HTML versions of
  86. those documents for the Web.  We do not need it as a way
  87. to interchange documents among Web browsers and create
  88. interoperable links; we have that
  89. level of standardization right now, and we have something
  90. that works.
  91.  
  92. Dale
  93.  
  94. -- 
  95.  
  96. Dale Dougherty 
  97. Digital Media Group, O'Reilly & Associates, Inc.
  98. 103A Morris Street, Sebastopol, California 95472 
  99. (707) 829-3762 (home office); 1-800-998-9938
  100.  
  101. UUCP:    uunet!ora!dale     Internet :   dale@ora.com
  102.